1. Technical Field
This invention relates generally to data transmission schemes and protocols. More particularly, the invention provides a method and apparatus for securely transmitting data between two or more computer nodes using an unreliable protocol such as User Datagram Protocol (UDP). Moreover, the invention provides a method and apparatus by which a communication session with a computer using the secure transmission of the invention can be switched to another computer without having to generate a new session.
2. Related Information
The well-known Transmission Control Protocol/Internet Protocol (TCP/IP) has been used for many years to transmit data packets between computers. TCP provides a guaranteed delivery and ordering scheme for data packets, such that two or more computers using TCP can rely on the protocol to ensure that any given packet will reach its destination in the order in which it was transmitted. Internet Protocol (IP) generally provides a point-to-point packet transmission service without guaranteed delivery. FIG. 1A shows how an application program can be layered on top of TCP/IP according to a conventional protocol stack. The popular Hyper Text Transport Protocol (HTTP) relies on the existence of a TCP connection between a client's browser and a server computer in order to fetch and display web pages.
Although TCP provides guaranteed delivery capabilities using built-in mechanisms (i.e., each application need not concern itself with reliability details), one disadvantage of using TCP is that it can incur delays and other side effects when transmitting a stream of data. For example, if two computers use TCP to transmit a packetized video stream, the received packets may appear “jerky” because missing or dropped packets must be re-transmitted before they can be re-ordered into the received packet stream. Consequently, TCP is not a good candidate for streaming data, such as videoconferencing applications.
The well-known User Datagram Protocol (UDP) provides a packet-oriented transmission service for communicating between two computers, such as a client computer and a server computer. In contrast to TCP and other guaranteed-delivery protocols, packets transmitted using UDP are not guaranteed to arrive at the destination computer. Moreover, packets that are transmitted in a particular order may arrive at the destination computer out of order. Thus, UDP is termed an “unreliable” transport protocol. In contrast to TCP and other guaranteed-delivery protocols, however, UDP provides a more time-sensitive delivery scheme, making it more suitable for streaming media such as video data.
As applications such as videoconferencing have increased the importance of streaming media, a need has arisen to provide secure streaming transmission facilities. For example, many corporations need to transmit streaming video between a headquarters facility and one or more remote offices. The transmission may include sensitive information that the company needs to protect from unintended recipients or eavesdropping. Because neither TCP nor UDP provide such security, they may be insufficient in themselves for such transmissions.
In recent years, various attempts have been made to provide secure transmission facilities by enhancing guaranteed-delivery protocols with encryption techniques. For example, the Secure Sockets Layer (SSL) is a protocol that provides a secure channel between two machines, such as a server computer and a client computer. The secure channel is transparent yet encrypted between client and server, such that nearly any protocol that can be run over TCP can be run over SSL with only minimal modifications. Indeed, SSL/TLS security and fault detection rely on TCP (or a similar guaranteed delivery protocol) to order packets and guarantee delivery. After undergoing various revisions, SSL was renamed Transport Layer Security (TLS) and adopted by the Internet Engineering Task Force (IETF), as reflected in RFC 2246. (The term SSL/TLS will be used to refer collectively to these two closely related protocols). A principal application of SSL/TLS is on-line shopping, wherein consumers transmit sensitive credit card information using HTTP protocols and web browsers in a secure manner.
Because most Internet protocols operate over TCP connections, SSL/TLS provides a convenient scheme for securely transmitting data between two or more computers, such as a client computer and a server computer. FIG. 1B shows architecturally how an application can use SSL/TLS to transmit secure data over a reliable connection such as TCP. As is conventional, the steps for securely transmitting data using SSL/TLS generally include the following:
(1) a client establishes a TCP connection with a server computer;
(2) the client and server use SSL/TLS protocols to exchange credentials (including an SSL/TLS handshake; negotiation of protocol mechanisms; and establishment of per-connection keys); and
(3) each HTTP request (e.g., GET) is converted into an SSL/TLS record having encrypted content.
FIG. 1C shows a sample SSL/TLS record, which generally includes a header (HDR), encrypted data or ciphertext, and a MAC (Message Authentication Check). The MAC ensures message integrity by means of a keyed hash, similar to a strong checksum, and is generally calculated as a function MAC=h(key, plaintext, sequence number), where the sequence number is a one-up counter for successive records. The sequence number forms an important aspect of the MAC calculated by TLS, since it prevents so-called “splicing attacks” that could otherwise occur if a hacker attempted to intercept and re-order packets in an attempt to decrypt or disrupt secure communication between computers using TLS. If the recipient's TLS detects an incorrect sequence number for a received record, it will reject the record as an attempted breach and terminate the connection. This requires that the sender and recipient re-establish another TCP connection, which results in wasted time and resources.
Because of its transparent nature, any TCP-based protocols (e.g., HTTP, FTP, etc.) or any similar guaranteed delivery protocol can be operated over TLS. Further details of SSL and TLS are provided in a book entitled “SSL and TLS: Designing and Building Secure Systems,” by Eric Rescorla, ISBN 0-201-61598-3, published by Addison Wesley.
Unfortunately, reliance on TCP or other guaranteed-delivery protocols renders SSL/TLS susceptible to the same performance problems that TCP incurs. For example, using SSL/TLS to transmit streaming video data incurs the same costs and penalties (e.g., “jerky” video) that the underlying TCP incurs. By its nature, SSL/TLS requires the use of a reliable connection such as provided by TCP, because they will terminate a connection if a packet is dropped or received out-of-order.
In recent years, a protocol known as Private Communication Technology (PCT) was proposed, although it was never commercially successful. PCT was an attempt to extend SSL to secure datagram traffic (using so-called “stream cipers”). For example, PCT used a different header format (4 bytes, 2 length and 2 record type) from SSL (5 bytes, 1 record type, 2 version number, 2 length). The handshaking message bodies also contained a different beginning format; PCT used 4 bytes (2 handshake type, 2 record flags), while SSL uses only 1 byte (handshake type). PCT datagram support used the following format:
2 bytes of key_length(key_length) bytes of key data(data_length) bytes of encrypted data(mac_length) bytes of MAC data,whereas SSL's datagram support is formatted as follows:
(data_length) bytes of encrypted data(mac_length) bytes of MAC(padding_length) bytes of padding1 byte of padding_length(nonce_length) bytes of nonce.PCT specified a mechanism in which every datagram has a new encryption key created by hashing a master key with the ENCRYPTED_KEY—1_DATA (a random value is assigned to each record that is part of DK_ENCRYPTED_KEY_DATA).
The proposed PCT mechanisms imposed various performance tradeoffs. For example, although the PCT mechanism could be used with stream ciphers, it is likely to be much slower, because of additional hashing and key schedule creation to process every single record. In other words, it uses a different key for every datagram, which is computationally costly. Key schedule setup can be expensive for some block ciphers. Moreover, PCT did not provide a mechanism for integration with the SOCKS or other multiprotocol proxies.
Conventional wisdom states that UDP is not suitable for secure communications. The Rescorla book identified above, for example, specifically states that “UDP does not [provide reliable transport] and so SSL cannot be successfully run over UDP, because records might be arbitrarily lost or reordered, which would look like an active attack to the SSL implementation.” Consequently, the prior art teaches away from using UDP in combination with SSL to transmit secure data. Yet UDP would be a good match for many streaming media applications, which can tolerate occasionally dropped data packets, but not delays that occur in TCP. For example, a videoconference that is broadcast in real-time can tolerate an occasionally missing video frame, but not the “jerkiness” that occurs when missing packets are retransmitted and reordered. Moreover, user session terminations occur frequently with standard UDP sent over standard SSL.
Some protocols rely on both TCP and UDP to transmit high-performance data, such as video or audio streaming. REALAUDIO, for example, is believed to use both TCP and UDP, wherein TCP is used for signaling (e.g., start/stop), while UDP is used to transmit data packets for the streaming content. However, the UDP datagrams are transmitted “in the clear,” rendering them susceptible to interception or attack.
A protocol known as KERBEROS, used mainly in academic circles, provides security by encrypting UDP datagrams. The mechanism used by KERBEROS to provide datagram security is specified in RFC 1964. However, it is not compatible with SSL/TLS protocols, and thus has not found widespread use. One of the primary reasons that KERBEROS has not been commercially successful is that it is complex to operate, and not streamlined for widespread use in network processing. In particular, network-based security software must interoperate efficiently with web servers and proxy servers to control and secure user access. In general, simpler protocols have been favored for fast processing and distributed systems.
KERBEROS also uses separate encryption mechanisms, namely key establishment handshakes, to communicate secure UDP and TCP traffic. However, it may be desirable to reduce computational and network traffic overhead by integrating those under a single standard security protocol, such as SSL, running on a multiprotocol proxy server standard such as SOCKS. KERBEROS also adds a random key field for packet identification to extend the data record in a conventional manner, for purposes of initializing the encryption algorithm. However, this requires additional computation and network traffic as KERBEROS has a separate sequence number in the data record. It may be advantageous in some systems to have a single field serving both purposes.
UDP and SSL are standards in the software industry. UDP is used for processing datagrams, while SSL provides secure communication. At the same time, the adoption of multiprotocol proxy servers, such as those running the popular SOCKS protocol, provide a means for combining industry standard communications protocols such as TCP and UDP in one system. Until recently, it has not been possible to do so because of the incompatibility of UDP and SSL. To understand this problem and the limitations it creates for management of network communications under a single proxy server protocol such as SOCKS, it is first necessary to understand how SOCKS processes information.
The SOCKS protocol provides a generic proxying protocol for traversing firewalls and other boundaries. Version 5 of this protocol, described in IETF RFC 1928, provides features such as authentication and UDP support. FIG. 2 shows a conventional approach for connecting to a server through a firewall by means of a proxy server and the SOCKS protocol. As shown in FIG. 2, a client computer 201 communicates with an application server 203 through a proxy server 202. The system may include a firewall (not shown) that acts as an application-layer gateway between networks. Application server 203 typically offers TELNET, FTP, SMTP, and HTTP access. Client computer 201 includes an application 2011 (e.g., a web browser) and a SOCKS client 2012. Proxy server 202 includes a SOCKS server 2021 and a proxy function 2022. In accordance with SOCKS version 5, which provides security features, client application 2011 can obtain services from server 203 as follows.
First, client application 2011 makes a request to connect to server 203. Next, SOCKS client 2012 detects the requested connection, and is aware that communication with server 203 must be handled via proxy server 202. Consequently, SOCKS client 2012 sends a request to SOCKS server 2021 to establish a TCP connection. Proxy function 2022 establishes a connection with server 203, and all further communication between client application 2011 and server 203 goes through SOCKS server 2021 and proxy function 2022. As is conventional, SOCKS uses SSL/TLS to establish a secure connection with client 201, and may demand a password before permitting the connection to be established. The architecture of FIG. 2 restricts access to server 203 at a single point (e.g., proxy server 202) and carries some of the load of communicating with server 203 in a way that penetrates firewalls. Because they rely on SSL/TLS to provide security, the connections in FIG. 2 necessarily rely on TCP (or a similar guaranteed-delivery protocol).
The architecture of FIG. 2 can also be used to transmit nonsecure UDP datagrams. This scheme involves negotiating a UDP port “connection” between client 201 and proxy server 202, such that nonsecure UDP datagrams are transmitted through the port, whereas secure commands are transmitted over the secured SSL/TLS/TCP connection. Such a scheme has sometimes been referred to as “naked UDP” mode, reflecting the fact that the UDP datagrams are unsecure. A system employing this technique has been commercially available from Aventail Corporation of Seattle, Wash., for several years. In general, SOCKS client 2012 adds a SOCKS header to each record transmitted from client 201, which is stripped off by SOCKS server 2021 before being transmitted to server 203.
As described above, it is not possible to securely transmit UDP datagrams in the context of SSL/TLS, due to SSL/TLS's reliance on TCP to provide a reliable connection service. However, it would be advantageous to provide a secure UDP service in the scheme of FIG. 2, such that proxy server 202 could facilitate high-performance video streaming between client 201 and server 203 without compromising the security of the data. Consequently, one challenge is to find a way to operate both secure TCP and secure UDP through proxy server 202, preferably using SSL as the security layer and SOCKS as the multiprotocol proxy server. More generally, it would be desirable to find a way to retain compatibility with the SSL/TLS standard without incurring the overhead and disadvantages caused by their reliance on TCP.
In addition to being unable to be successfully run over UDP, the SSL/TLS protocols offer another drawback. In the example described above, the client device 201 initiates a secure protocol session with the proxy server 202 by completing a full SSL/TLS “handshake” with the proxy server 202. During this handshake, the client computer 201 and the proxy server 202 exchange SSL/TLS version numbers, cipher settings, session-specific data, authentication certificates, and other information that they need to communicate with each other using the SSL/TLS protocol. Using this information, both the client computer 201 and the proxy server 202 generate the same master secret key, which in turn is used to generate individual session keys. These session keys are symmetric keys used to encrypt and decrypt individual groups of information exchanged during the session, and to verify the integrity of exchanged information.
As will be appreciated by those of ordinary skill in the art, conducting a full SSL/TLS handshake to initiate a SSL/TLS session is time consuming and presents a heavy load on the network's resources, both in terms of network communication traffic and in processing time for the client device 201 and the proxy server 202. Once the proxy server 202 has received the required SSL/TLS session information in a full SSL/TLS handshake, however, the proxy server 202 may subsequently resume that SSL/TLS session with the client computer 201 using only a partial SSL/TLS handshake. Advantageously, the partial SSL/TLS handshake is much quicker and consumes less network resources than the full SSL/TLS handshake.
A problem with this arrangement occurs, however, if the connection between the client computer 201 and the proxy server 202 is terminated and the client computer 201 then tries to establish communication with the application server 203 through another proxy server 202. For example, the first proxy server 202 may have failed and be unavailable, or a load balancer may simply have routed the new connection from the client device 201 to the new proxy server 202 to reduce the communication load on the first proxy server 202. In any case, the new proxy server 202 will not have the SSL/TLS session information needed to resume the SSL/TLS session with the client computer 201. Accordingly, the client device 201 and the new proxy server 202 must conduct a full SSL/TLS handshake in order to create a new SSL/TLS communication session. This process is time-consuming, and may require a substantial amount processing time from both the client computer 201 and the new proxy server 202. Moreover, depending upon the state of the original session between the client device 201 and the proxy server 202, the loss of the previous session's state may be irreplaceable. For example, if the state of the earlier session was established by exchanging data that cannot be duplicated, then that session cannot be recreated.
To address this problem, some network systems attempt to ensure that a terminated connection between a client computer 201 and its associated proxy server 202 is reestablished with that original proxy server 202 rather than with a new proxy server device 202. For example, some systems design a load balancer to recognize when the client device 201 has established a session with a particular proxy server 202, and then route all future connections from the client computer 201 to that proxy server 202. This solution has a number of drawbacks, however. It requires that the load balancer be very complex and perform a variety of functions. Further, it does not address the situation that occurs if the initial proxy server 202 becomes unavailable, e.g., if it fails and simply cannot reestablish a connection with the client computer 201. It also does not address the situation where the first proxy server 202 becomes overloaded with connections to other client computers. In effect, this solution may prevent the load balancer from performing a load balancing function.
In view of the failure of conventional attempts to providing secure data transmission facilities without incurring the penalties and overhead inherent in reliable communication protocols, there exists a need to provide such facilities to support high-bandwidth applications such as secure videoconferencing. Moreover, there is a need to provide secure data transmission services while retaining compatibility with SSL/TLS. Further, there is a need for a network arrangement that will allow a client computer to switch between a communication connection with a first proxy server to a second proxy server while maintaining the state of a SSL/TLS session established between the client computer and the first proxy server. Preferably, such a network arrangement should permit such a switch from a connection with a first proxy server to a connection with a second proxy server even if the first proxy server becomes unavailable due to failure or other problems.